<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0031) -->
<HTML><HEAD><TITLE>SMS messages and the PDU format</TITLE>
<META http-equiv=Content-Type content="text/html; charset=windows-1252">
<META content="SMS messages and the PDU format" name=description>
<META 
content="Lars Pettersson SICS SMS PDU GSM ETSI OTA provisioning settings configuration" 
name=keywords>
<META content="MSHTML 5.50.4807.2300" name=GENERATOR></HEAD>
<BODY bgColor=white><IMG src="gsmlogo.gif" 
align=sd> <BR><BR>
<H1>SMS and the PDU format</H1><BR>
<H3>Introduction</H3>The SMS message, as specified by the <A 
href="http://www.etsi.org/">Etsi</A> organization (documents GSM 03.40 and GSM 
03.38), can be up to 160 characters long, where each character is 7 bits 
according to the <A 
href="default_alphabet.html"><I>7-bit default 
alphabet</I></A>. Eight-bit messages (max 140 characters) are usually not 
viewable by the phones as text messages; instead they are used for data in e.g. 
smart messaging (images and ringing tones) and <A 
href="http://www.3glab.org/ota.html">OTA provisioning of WAP settings.</A> 
16-bit messages (max 70 characters) are used for Unicode (UCS2) text messages, 
viewable by most phones. A 16-bit text message of class 0 will on some phones 
appear as a <A href="alert.html">Flash SMS</A> 
(aka blinking SMS or alert SMS). <BR><BR><BR>
<H3>The PDU format</H3>There are two ways of sending and receiving SMS messages: 
by text mode and by PDU (protocol description unit) mode. The text mode 
(unavailable on some phones) is just an encoding of the bit stream represented 
by the PDU mode. Alphabets may differ and there are several encoding 
alternatives when displaying an SMS message. The most common options are 
"PCCP437", "PCDN", "8859-1", "IRA" and "GSM". These are all set by the <A 
href="faq59.htm">at-command</A> AT+CSCS, when you 
read the message in a computer application. If you read the message on your 
phone, the phone will choose a proper encoding. An application capable of 
reading incoming SMS messages, can thus use text mode or PDU mode. If text mode 
is used, the application is bound to (or limited by) the set of preset encoding 
options. In some cases, that's just not good enough. If PDU mode is used, any 
encoding can be implemented. <BR>
<H3>Receiving a message in the PDU mode</H3>The PDU string contains not only the 
message, but also a lot of meta-information about the sender, his SMS service 
center, the time stamp etc. It is all in the form of hexa-decimal <I>octets</I> 
or decimal <I>semi-octets</I>. The following string is what I received <I>on a 
<A href="http://www.nokia.com/phones/6110/index.html">Nokia 6110</A></I> when 
sending the message containing "hellohello" from <A 
href="http://www.mtn.co.za/">http://www.mtn.co.za/</A>. <BR><BR>
<TABLE>
  <TBODY>
  <TR>
    <TD bgColor=yellow>07</TD>
    <TD bgColor=cyan>917283010010F5</TD>
    <TD>040BC87238880900F10000993092516195800AE8329BFD4697D9EC37</TD></TR></TBODY></TABLE><BR>This 
octet sequence consists of three parts: An initial octet indicating the length 
of the SMSC information ("07"), the SMSC information itself ("917283010010F5"), 
and the SMS_DELIVER part (specified by ETSI in GSM 03.40). <BR><BR><I>Note: on 
some phones (e.g. Ericssson 888?) the first three (colored) parts are omitted 
when showing the message in PDU mode!</I> <BR><BR>
<TABLE border=1>
  <TBODY>
  <TR>
    <TH>Octet(s)</TH>
    <TH>Description</TH>
  <TR></B>
    <TD bgColor=yellow>07</TD>
    <TD>Length of the SMSC information (in this case 7 octets)</TD>
  <TR>
    <TD bgColor=cyan>91</TD>
    <TD><A 
      href="type_of_address.html">Type-of-address</A> 
      of the SMSC. (91 means international format of the phone number)</TD>
  <TR>
    <TD bgColor=cyan>72 83 01 00 10 F5</TD>
    <TD>Service center number(in decimal semi-octets). The length of the phone 
      number is odd (11), so a trailing F has been added to form proper octets. 
      The phone number of this service center is "+27381000015". See below.</TD>
  <TR>
    <TD>04</TD>
    <TD><A href="deliver_fo.html">First octet 
      of this SMS-DELIVER message</A>.</TD>
  <TR>
    <TD>0B</TD>
    <TD>Address-Length. Length of the sender number (0B hex = 11 dec)</TD>
  <TR>
    <TD>C8</TD>
    <TD><A 
      href="type_of_address.html">Type-of-address</A> 
      of the sender number</TD>
  <TR>
    <TD>72 38 88 09 00 F1</TD>
    <TD>Sender number (decimal semi-octets), with a trailing F</TD>
  <TR>
    <TD>00</TD>
    <TD>TP-PID. <A href="pid.html">Protocol 
      identifier</A>.</TD>
  <TR>
    <TD>00</TD>
    <TD>TP-DCS <A href="dcs.html">Data coding 
      scheme</A></TD>
  <TR>
    <TD>99 30 92 51 61 95 80</TD>
    <TD>TP-SCTS. <A href="scts.html">Time 
      stamp</A> (semi-octets)</TD>
  <TR>
    <TD>0A</TD>
    <TD>TP-UDL. User data length, length of message. The TP-DCS field 
      indicated 7-bit data, so the length here is the number of septets (10). If 
      the TP-DCS field were set to indicate 8-bit data or Unicode, the length 
      would be the number of octets (9). </TD>
  <TR>
    <TD>E8329BFD4697D9EC37</TD>
    <TD>TP-UD. <A href="hello.html">Message 
      "hellohello"</A> , 8-bit octets representing 7-bit data.</TD>
  <TR></TR></TBODY></TABLE><BR>All the octets above are hexa-decimal 8-bit octets, 
except the Service center number, the sender number and the timestamp; they are 
decimal semi-octets. The message part in the end of the PDU string consists of 
hexa-decimal 8-bit octets, but these octets represent 7-bit data (see below). 
<BR><BR>The semi-octets are decimal, and e.g. the sender number is obtained by 
performing internal swapping within the semi-octets from "72 38 88 09 00 F1" to 
"27 83 88 90 00 1F". The length of the phone number is odd, so a proper octet 
sequence cannot be formed by this number. This is the reason why the trailing F 
has been added. The time stamp, when parsed, equals "99 03 29 15 16 59 08", 
where the 6 first characters represent date, the following 6 represents time, 
and the last two represents time-zone related to GMT. <BR><BR>
<H3>Interpreting 8-bit octets as 7-bit messages</H3>This transformation is 
described in detail in GSM 03.38, and an <A 
href="hello.html">example of the "hellohello" 
transformation is shown here</A>. The transformation is based on the <A 
href="default_alphabet.html">7 bit default 
alphabet</A> , but an application built on the PDU mode can use any character 
encoding. 
<H3>Sending a message in the PDU mode</H3>The following example shows how to 
send the message "hellohello" in the PDU mode from a Nokia 6110.<BR><BR><XMP>AT+CMGF=0    //Set PDU mode          
AT+CSMS=0    //Check if modem supports SMS commands          
AT+CMGS=23  //Send message, 23 octets (excluding the two initial zeros) 
>0011000B916407281553F80000AA0AE8329BFD4697D9EC37<ctrl-z> 
</XMP>There are 23 octets in this message (46 'characters'). The first octet 
("00") doesn't count, it is only an indicator of the length of the SMSC 
information supplied (0). The PDU string consists of the following:<BR><BR>
<TABLE border=1>
  <TBODY>
  <TR>
    <TH>Octet(s)</TH>
    <TH>Description</TD> </TR>
  <TR>
    <TD bgColor=yellow>00 </TD>
    <TD>Length of SMSC information. Here the length is 0, which means that the 
      SMSC stored in the phone should be used. <I>Note: This octet is optional. 
      On some phones this octet should be omitted! (Using the SMSC stored in 
      phone is thus implicit)</I> </TD></TR>
  <TR>
    <TD>11 </TD>
    <TD><A href="submit_fo.html">First octet of 
      the SMS-SUBMIT message</A>. </TD></TR>
  <TR>
    <TD>00 </TD>
    <TD>TP-Message-Reference. The "00" value here lets the phone set the 
      message reference number itself. </TD></TR>
  <TR>
    <TD>0B </TD>
    <TD>Address-Length. Length of phone number (11) </TD></TR>
  <TR>
    <TD>91 </TD>
    <TD><A 
      href="type_of_address.html">Type-of-Address.</A> 
      (91 indicates international format of the phone number). </TD></TR>
  <TR>
    <TD>6407281553F8 </TD>
    <TD>The phone number in semi octets (46708251358). The length of the phone 
      number is odd (11), therefore a trailing F has been added, as if the phone 
      number were "46708251358F". Using the unknown format (i.e. the 
      Type-of-Address 81 instead of 91) would yield the phone number octet 
      sequence 7080523185 (0708251358). Note that this has the length 10 (A), 
      which is even. </TD></TR>
  <TR>
    <TD>00 </TD>
    <TD>TP-PID. <A href="pid.html">Protocol 
      identifier</A> </TD></TR>
  <TR>
    <TD>00 </TD>
    <TD>TP-DCS. <A href="dcs.html">Data coding 
      scheme</A>.This message is coded according to the 7bit default alphabet. 
      Having "04" instead of "00" here, would indicate that the TP-User-Data 
      field of this message should be interpreted as 8bit rather than 7bit (used 
      in e.g. smart messaging, OTA provisioning etc). </TD></TR>
  <TR>
    <TD>AA </TD>
    <TD><A 
      href="vp.html">TP-Validity-Period</A>. "AA" 
      means 4 days. <I>Note: This octet is optional, see bits 4 and 3 of the <A 
      href="submit_fo.html">first octet</A></I> 
    </TD></TR>
  <TR>
    <TD>0A </TD>
    <TD>TP-User-Data-Length. Length of message. The TP-DCS field indicated 
      7-bit data, so the length here is the number of septets (10). If the 
      TP-DCS field were set to 8-bit data or Unicode, the length would be the 
      number of octets. </TD></TR>
  <TR>
    <TD>E8329BFD4697D9EC37 </TD>
    <TD>TP-User-Data. These octets represent the message "hellohello". How to 
      do the transformation from 7bit septets into octets is shown <A 
      href="hello.html">here</A> 
    <TD></TD></TR></TBODY></TABLE><BR>
<H2>Links</H2>
<UL>
  <LI><A href="cms_error.html">CMS error 
  codes</A> 
  <LI><A href="http://www.nobbi.com/sms_pdu.htm">Versenden von Kurznachrichten 
  mittels PDU</A> 
  <LI><A href="http://www.etsi.org/">Etsi</A> </LI></UL><BR><FONT size=2>
<ADDRESS>This page has been visited 160808 times and is written and maintained 
by Lars Pettersson (<A 
href="mailto:lars.pettersson@email.nu">lars.pettersson@email.nu</A>).</ADDRESS></FONT>
<P></P></BODY></HTML>
